I ran some tests yesterday...

1) I STRONGLY recommend looking at your cfg file in a hex editor before
attempting to upload it to make sure that it has a cr lf line terminators.
That is hex 0D 0A
You may have multiple pairs between lines but you must at least have the 0A
It wont look right in notepad of you are missing the pair, and it wont work
when gets on the controller in certain send scenarios, so don't do it if its
not right!!

Some text editors - like ones that ask 'Do you want to convert to DOS' or
something similar may cause a problem - but xfering w/hyperterm definitely
can cause problems regardless of the editor you use depending on your coms
settings.

If the file 'looks right' in notepad, that's a good sign but still - look in
a hex editor!!  XVI32 works quite well and is freeware
http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm


OK, here is what I found....

2) ABSOLUTELY::: upload to a temporary file on the controller ** NOT TO
OASIS.CFG !!! ****. They type it back to see that its not "all on one line"
then its probably safe to rename it to oasis.cfg and reboot.

3) It makes a big difference to hyperterm if you are at the OASIS> prompt or
in picodos...

4) Craig etal suggest going from picodos with a yr command, but I don't like
to because if you forget your connected via radio you may be SOL for 30
minutes because you'll probably kill the radio driver and have to wait for
32 minutes for the hardware to rest(I have not tested that, Im trying at my
desk right now...).

5) I prefer to use "capture" command and motocross but you need a version
that has the "Transfer>SendBinaryFile" menu item. (eg. v2.32 has it, an
older version that Paul found out at sea did not)

6) If you must, you can use hyperterm with the capture command and
"Transfer>SendTextFile" but you ***ABSOLUTELY MUST FIRST SET "Send line ends
with line feeds" PRIOR TO TRANSMITTING THE FILE***   My tests show that
using capture at the oasis prompt with this setting off, causes hyperterm to
strip the lf in your cfg file.  Then the file on the controller appears as
all on one line when typed back.

7) Motocross "send binary file" works from either the picodos or OASIS>
capture command (as long as you obey rule #1)  In all cases, its "Comm
Settings > "Send LF after CR" was un-checked.

8a) Hyperterm works ok from OASIS> prompt IF the "Send Line ends with Line
Feeds" is TRUE. (but you may later want to reset it to false so you don't
get "Double OASIS> prompts"
8b) Hyperterm works ok from picodos C:\> prompt IF the "Send Line ends with
Line Feeds" is FALSE. (also will work ok if TRUE but then you get the double
prompt symptom.

*************************** THE BOTTOM LINE(S) *****************************
USE dumb editors, check line endings with XVI32 to verify Rule#1 and xfer to
a temp file (Rule#2) using MOTOCROSS !!!!
(Or only if brave or hardwired to console port, you can use yr from picodos)
****************************************************************************

If your forced to deal with an oasis.cfg file that may not have correct line
endings even though it looks ok in notepad....  and you have no hex editor
to verify...
(eg. When you upload the file per recommendations above, it still is all on
one line) It seems in my quick testing that you can use notepad to add extra
lines at every line and then re-upload...(you will have line endings in hex
editor of 0D 0D 0A which still seems to be ok with OASIS>)

Curious if anyone else has experiences that differ from above, it would be
great to nail this down and cookbook it along with how to recover if you do
screw things up......

-Rich 
If you mistakenly issue the "reset pico" command while connected to the
radio port, you will loose contact... The only ways to get it back are to:
1)Bounce the power
2)Wait ~32 minutes for the hardware reset (plus the wait for the radio
wakeup procedure)

Fortunately in the next release of code (still in testing), Bob added a
warning message with a Y/N to remind you your on the radio... (Thanks Bob!)


And please correct my last.... re:  picodos using yr (ymodem receive...) is
from hyperterm (motocross doesn't support ymodem file xfers....)

-Rich

Another follow up to this thread... sorry for the overkill.

We successfully transferred a new oasis.cfg file to 2010M1 via radio
link on Tuesday afternoon.  

The file was edited with a hex editor to include the correct 0D 0A line
terminators.  There were places where there were two in a row (0D 0A 0D
0A) but in no cases were there multiple 0Ds before a single 0A as I've
run across in some other oasis.cfg files that are floating around (0D 0D
0A).

Once the file was edited and double checked, we transferred it according
to Rich's procedure in #6 below and detailed here:

-Establish link with mooring
-At oasis prompt, type "capture [filename] <enter>"
-Go to HyperTerm properties, 'settings' tab, click 'ascii setup' button,
check 'Send line ends with line feeds' button
-Go to HyperTerm Transfer menu, and select 'Send Text File...'
-Select file to send and wait for file transfer
-At oasis prompt, type "^D" to close capture on oasis
-Go back to HyperTerm properties and uncheck 'Send line ends with line
feeds'
-Check file on can to make sure it looks right (at oasis prompt, type
"type [filename]")
-If all looks correct, rename files (oasis.cfg to [oasis.bk?] and
[filename] to oasis.cfg) and reset mooring.
-Sacrifice a small animal (or vegetable for the vegetarians) to the
mooring gods
And finally...
-Blame Rich if it doesn't work for you

Just wanted to document the successful file transfer over the radio.
The mooring came back immediately, and everything appears to be working
well.

Paul

P.s.  In #1 below, Rich says that he strongly recommends checking the
file in a hex editor.  I think this should be an absolute requirement.

A couple of notes regarding the oasis.cfg file issue from Wednesday's deployment:
 
First off, we were NOT able to modify the config file with the new pCO2 constants before it was deployed...
Attempts to transfer the new file to the controller on the buoy did not appear to work, and looked (for about ten minutes there) like it corrupted the entire oasis directory.  Due to past issues of corrupting the oasis controller with bad oasis.cfg files, and the above scare that the oasis directory was destroyed while on the way out to deploy the buoy, I was unwilling to continue attempting to get a file across to the controller.  So unfortunately the constants are not correct for the pCO2 that is on the buoy.
 
Secondly, the config file needs to be in its deployment form at the time the oasis can is closed!!
Because there are some idiosyncrasies with this file transfer, having it on the bench gives plenty of time to recover if there is an issue.  As of a week before deployment, the entire systems should ideally be hands off, and this definitely needs to be the case for all software/firmware on the can.  Further bench testing (Thanks Rich!!) has shown that we may have nailed down the problem with the file transfer, but until additional testing shows that we can reliably do this over the radio on the buoy, no changes should be made after the can is closed.
 
Some pCO2 specific thoughts:
I know it's been this way for a long time (forever?), but why are the pCO2 constants contained in the oasis.cfg file?  This is the only instrument-specific information contained in the oasis.cfg file (other than driver info); what would we need to do to bring them out?  Ideally we would have them on shore for post processing, but if they need to absolutely be on the buoy, can they be in a separate file (pCO2.cfg maybe)?  Maybe have a line in the oasis.cfg that would point to the pCO2 config file?  With this information no longer in the oasis.cfg file, there is not the same danger of hanging the entire buoy if the file becomes corrupt in the transfer.  It will also allow us to change the pCO2 constants if the instrument ever needs to be swapped in the field.  I'm sure this has been considered before... I've either forgotten the answer, or wasn't in on the discussion.  Apologies if I'm digging up old info.
 
Thanks,
Paul
 
 

On another note, if we can *ever* get up to speed with the most current
checked-in code, (that is, if we can switch to the new radios and
wire protocol), it's worth noting that this new code also has some
line editing features.  They've turned out to be extremely useful
for the respirometers, which are based on Oasis and where the line
editor commands originated.  Allows you to add, delete, and comment-out
lines in OASIS.CFG in situ, which greatly reduces the need for
transferring files.
-Bob